Friendly bump -- let me know if anything needs changing.

Does the same fix path also cover a server returning 200 with an empty body, or 200 with valid JSON for a different request id? Both have the same "initialize never resolves" shape, so if the fix is at the right layer they should unblock without new code. If those cases are tested elsewhere already, ignore.

No — this test is scoped to the unexpected content-type path only. The hang in issue #2432 is triggered when the SDK reaches the if content_type not in ("application/json", "text/event-stream") guard and raises McpError; the initialize() future is resolved by that error propagation.

The two cases you describe follow different paths:

• 200 with empty body: content-type would still be application/json (or absent), so it bypasses the content-type check. The body JSON-parse would fail or produce an empty response, which is a separate code path — likely a different hang or error class.
• 200 with valid JSON for a different request id: the response matcher would never complete the outstanding initialize future since the id doesn't match, so the session would hang differently — at the response-matching layer, not the content-type layer.

Both are valid "initialize never resolves" failure modes but would need separate tests against the relevant code paths. Happy to add them here or in a follow-up PR if that's useful.